Streaming media is multimedia that is constantly received by, and normally presented to, an end-user (using a client) while it is being delivered by a streaming provider (using a server). Several protocols exist for streaming media, including the Real-time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP), and the Real-time Transport Control Protocol (RTCP), which are often used together. The Real Time Streaming Protocol (RTSP), developed by the Internet Engineering Task Force (IETF) and created in 1998 as Request For Comments (RFC) 2326, is a protocol for use in streaming media systems, which allows a client to remotely control a streaming media server, issuing VCR-like commands such as “play” and “pause,” and allowing time-based access to files on a server.
The Internet contains many types of downloadable media content items, including audio, video, documents, and so forth. These content items are often very large, such as video in the hundreds of megabytes. Documents are often retrieved over the Internet using the Hypertext Transport Protocol (HTTP) through a web browser or other application. The Internet has built up a large infrastructure of routers and proxies that are effective at caching data for HTTP. Cached data can be provided to clients with less delay and by using fewer resources than re-requesting the content from the original source. For example, a user in New York may download a content item served from a host in Japan and receive the content item through a router in California. If a user in New Jersey requests the same file, the router in California may be able to provide the content item without again requesting the data from the host in Japan. This reduces the network traffic over possibly strained routes, and allows the user in New Jersey to receive the content item with less latency.
Often, a user is only interested in a portion of a large content item, such as a particular page of a large PDF or a particular time range in a large video. Unfortunately, the only way to get the desired portion of the content item in some cases is to download the entire content item to the user's computer and then open the content item to find the portion of interest. Even if a user could retrieve a portion of a large content item, it is desirable for the portion to be cacheable by the existing Internet infrastructure, and to be compatible with later downloading of additional portions of the same content item.
One prior attempt to solve this problem is HTTP byte ranges or byte serving. Byte serving is the process of sending only a portion of an HTTP/1.1 message from a server to a client. In the HTTP/1.0 standard, clients were only able to request an entire document. By allowing byte serving, HTTP/1.1 allows clients to choose any portion of the resource by specifying the bytes of the resource to download. One use of this capability is that when a large file is being requested, and that media file is properly formatted, the client may be able to request just the portions of the file known to be of interest. Even where files are not specially formatted, clients can retrieve portions of the files using byte range requests. For example, a client could send a byte range request to get a portion of an image file (e.g., a JPG or GIF). Most mainstream web servers support byte range requests, so any type of content served by most websites can be retrieved using byte ranges.
Unfortunately, it is difficult to cache HTTP resources requested by byte range. When a cache receives a request for a byte range of a resource that is not already in the cache, past systems handle the request using one of two strategies. The first strategy is to start retrieving the content resource from the beginning and reply to the request when enough of the content is in the cache to satisfy the request. The cache can then continue to retrieve the full content resource after replying to the request. This strategy introduces an amount of extra latency relative to the offset of the byte range from the beginning of the content resource that may be unacceptable for many applications. This strategy may also include an offset threshold, where requests for offsets outside the threshold are not retrieved from the beginning. Instead, such requests may just be proxied to the content server to keep the extra latency of downloading the unrequested range of content at an acceptable level. This can lead to fewer cache hits as many requests may fall outside of the offset threshold. The second strategy is for a cache to send a second request for a full content resource after an initial cache miss related to a byte range request. This adds an extra request and burden to the origin server and increases the overall amount of data retrieved. For both of these strategies, a cache hit cannot occur unless the full content resource is stored in the cache.